perm filename DIALNE.MEM[DLN,MRC] blob
sn#325544 filedate 1977-12-26 generic text, type C, neo UTF8
COMMENT ā VALID 00009 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Dialnet Memo #1
C00003 00003 THE DIALNET CONCEPT
C00009 00004 THE DIALNET CONCEPT (continued)
C00012 00005 SCENARIO
C00017 00006 SCENARIO (continued)
C00019 00007 PROTOCOLS
C00023 00008 RESEARCH ISSUES
C00026 00009 RESEARCH PLAN
C00029 ENDMK
Cā;
Dialnet Memo #1
DIALNET
John McCarthy and Les Earnest
12/26/77
These protocols are being developed as part of the Dialnet project at the
Stanford University Artificial Intelligence Laboratory supported by NSF grant
MCS 77-02080 with John McCarthy as Principal Investigator.
This is DIALNE.MEM[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
THE DIALNET CONCEPT
Dialnet will be a set of protocols (like those of the ARPAnet) enabling a
computer user at a terminal attached to his own computer to send messages to
users of other computers, to transmit files between his own and other computers,
and to use other time-shared computers directly - all using the facilities of
the ordinary dial-up telephone network. His computer will need a telephone
dialer and a suitable modem and must implement the Dialnet protocols in its
operating system.
The Stanford University Artificial Intelligence Laboratory, with support
from the National Science Foundation starting 1 July 1977, has begun an eighteen
month study which will design and experimentally implement suitable protocols.
While we expect the main users of Dialnet to be time-sharing systems, we
hope the protocols will be implementable by single user computer systems,perhaps
even down to the level of hobbyist computers. We call the system Dialnet by
analogy with ARPAnet, but unlike the ARPAnet, it requires no administrator to
"admit" new members; they need only implement the protocols and know each
other's telephone numbers.
We need and solicit the co-operation of computer users and manufacturers in
developing protocols that will be suitable for standardization. Mistakes made
now may have a long life.
The ARPAnet connects about a hundred computer facilities involved in
Defense Department supported research and allows users of one system to log in
on others, allows transmission of messages between users of different computers,
and allows the transfer of files between computers. More generally, it allows
interaction among programs in different computers.
These facilities have proven valuable in aiding collaboration among
computer scientists at different sites and in permitting nationwide access to
unique facilities such as the MACSYMA system for computing with algebraic and
analytic expressions at M.I.T. They permit a new form of publication in which
documents are kept in the computer, are continuously updatable, are immediately
accessible throughout the country, and in which comments from readers are
accessible to other readers.
The usefulness of the ARPAnet has prompted many non-defense installations
to try to connect to it, and in some cases this has been possible, but usually
the institutional and financial obstacles have been insuperable.
The main financial obstacles are the need for a dedicated computer called
an IMP costing about $80,000 at each site and the need for dedicated
communication lines rented by the Department of Defense at great expense from
the telephone companies. Other networks have been started, some for particular
user populations and others on as common carriers. However, they have higher
base and overhead costs than can be achieved with direct use of the telephone
system and don't presently offer message, file transfer and login services.
We propose to design protocols that can be implemented at any time-shared
computer installation or single user computer system without joining any formal
network. The hardware cost will be from $500 to $5000 depending on the type of
system and how difficult it is to connect devices to the computer. For
timesharing systems, a telephone dialer will be rented from the telephone
company so that the system can initiate calls. For small single-user systems
where economy is paramount, the user can do his own dialing to initiate a call.
There will be programs to transmit signals and information according to the
THE DIALNET CONCEPT (continued)
protocols. Any installation implementing the protocols will be able to
communicate with any other. The only disadvantage compared with the ARPAnet
will be lower speed.
Like ARPAnet, Dialnet will be most useful to full time-sharing systems or
single user systems that operate 24 hours and have file systems. In such
systems, each user has named disk files that are kept in the system even when he
is absent (and therefore remotely accessible), and new files can be created by
file transfer from other machines and on receipt of messages. The usefulness of
the message facilities normally requires that users habitually log in each
working day and are most beneficial when users have individual display terminals
in their offices. Further benefits accrue when reports are normally prepared at
terminals and when secretaries use terminals for letters and messages. However,
many less advanced installations have found the ARPAnet useful and more and more
systems are acquiring economical full time-sharing capability.
While we expect the first users of Dialnet to be regular computer users,
the corresponding ARPAnet facilities have been much used by non-programmers.
Users of Dialnet need not know how to program, and we expect increasing use by
non-programmers as terminals become more widespread.
In order to make the picture more concrete, here is a scenario of the use
of the system suitable for scientists. Other potential users may imagine their
own scenarios. The syntax contained in the scenario is not a proposal; we will
have to think much more before we have such a proposal.
SCENARIO
A user named Smith types on his terminal
mail Organik
Do you have any active work there on human red cell carbonic
anhydrase B?
The system looks up Organik in Smith's correspondent file and discovers
that his computer pseudonym is "NAT" at a computer called UTEX-CHEM1 that is
reached at (512) 471-3221 via a 1200/150 baud asychronous modem. It selects an
outgoing line with a matching modem, dials the number and attempts to transmit
the message. If the transmitting computer cannot elicit a response from the
desired recipient, it informs the user that it will try again later and send him
a message when the transmission has succeeded. If the user's correspondent file
did not contain the telepone number and modem characteristics, the user would
have to supply them.
The identity and location of the sender and date and time of the message
are automatically placed at the front of the message. At the receiving end, if
the addressee is logged in on the computer, he is immediately informed that mail
has arrived and from whom. If not logged in, he will receive the message the
next time he logs in. In either case, he can use the same facility to respond:
mail Smith
David Piranha (DAVE@UTEX-CHEM3) has a student working on
inhibition by anions of anhydrase B.
Following up on this lead, the user types
link Dave@utex-chem3
A connection is made to the specified computer and, if DAVE is logged in,
he immediately receives a message saying
** Link request from Smith @SU-CHEM7 **
He could then type "link" and have his keyboard and display effectively
linked to those of the caller, permitting a conversation.
Let us suppose, however, that DAVE is not logged in and the caller is so
informed. He then types
locate dave@utex-chem3
which obtains the following information from the specified computer:
David Piranha last logged out at 23:47 on May 9, 1976. Plan:
I will be out of touch May 10 through 16. I plan to visit
Martin Shumway at the University of Utah on May 17 and
should return by May 18. Will check mail from Utah.
Noting that the current date is May 14, so that there is no point in
getting the message there quickly, Smith types
night mail dave@utex-chem3
I am interested in your work on anhydrase B. If possible,
give pointers to online documentation, else give me a call
at (415) 497-4430 (Stanford) or (415) 321-7580 (home).
SCENARIO (continued)
The "night mail" command causes the message transmission to be deferred
until inexpensive nighttime telephone rates are in force.
Additional capabilities of the Dialnet system can be used to follow up on
the above inquiry, as follows:
The ability to access remote text files will be provided
(with permission of the owners required, of course). This
interactive reading facility will include the addition of
"footnotes" to various parts of the text. These footnotes
may be declared private (i.e. belonging to the reader) or
public (available to the author and possibly others).
It will be possible to run programs on a remote computer,
permitting experiments with programs developed in other
places. This facility will permit the sharing of unique
specialized capabilities over a geographically distributed
population.
File transfers will be permitted, with suitable error
detection and correction features, to permit sharing of
data. The communication protocol should be able to adapt to
a wide range of noise conditions on phone lines.
PROTOCOLS
In order to make these facilities available, suitable protocols must be
designed, and in the course of this, a number of technical problems must be
solved. Besides the protocols themselves, which are communication procedures
and data structures, there will be a recommended set of terminal-level commands
with syntax prompting and standard error messages.
We believe that we have the experience to produce a set of workable
protocols, and that it is better to start with an implementation than to
standardize something that doesn't exist. The latter procedure in recent years
has led to gold-plating the requirements to the extent that the standard is not
implementable.
We plan to devise suitable protocols, test them at a few sites, publish
them, and attempt to convince other installations to implement them. Almost
certainly, initial experience will produce a requirement for changes, and
standardization committees will be formed and set to work. A likely forum for a
standardization effort would be through the ACM to the American National
Standards Committee.
We propose to allow interaction with ARPAnet sites via TIPs and propose to
discuss with ARPA and DCA whether this will be allowed.
The most general use of Dialnet involves a program in one computer "waking
up" and interacting with a program in another machine. Dialnet protocols will
handle human messages as a subcase of this, taking into account the fact that
the subcase will have the most application for a long time to come. Messages
about where to deliver a message sent by one time-sharing system to another will
be handled as a special sort of message that one program may send another in
cases where the two programs are not written together, but each must know a
certain "public" language. Thus we will attempt to make a general format for
requests, questions, and assertions suitable for communication between computer
programs. We will study how to make this mesh with communication between
computer programs and people.
RESEARCH ISSUES
There are many research issues, and we don't expect to settle all of them
in the time and with the resources requested in this proposal. Since we expect
many of the issues will be clarified by the initial implementation, we will
concentrate on getting a reasonable first implementation into experimental use.
Here are some of the issues we will study:
1. What error correction facilities are required to make up
for the deficiencies of telephone lines?
2. What is the minimal necessary burden on the time-sharing
computers carrying out the communication? What is the
trade-off between buffer size and compute time?
3. Can dial-up telephone communication rates meet most of
the needs for communication between computers belonging to
different research organizations?
4. What is the best way to handle the fact that different
modem speeds have different prices? Should one strive for a
standard speed or can a wide variety be easily accomodated?
Is the time ripe for a micro-processor based modem that can
communicate at any speed up to a maximum and adjust its
speed to the requirements of the line or the possibly less
advanced modem with which it communicates?
5. How will the improved communication affect research?
Since changes will be slow, how can we tell as early as
possible what the effects will be?
6. What style of interaction is convenient for both
experienced and inexperienced users? How can communication
programs be made self-teaching without being cumbersome?
RESEARCH PLAN
We plan to undertake this project with rather modest staffing. Initial
emphasis will be on designing and implementing experimental protocols using
existing computer facilities at Stanford. We will also rely heavily on the
co-operation of other organizations that have expressed interest in the project
both in determining the protocols and in implementing them for specific
machines. Two of the initial implementations will be at the computer facilities
of the Stanford Artificial Intelligence Laboratory (SAIL) and the Low Overhead
Timesharing System (LOTS), also at Stanford. The latter is a DECsystem-20 using
the TOPS-20 operating system, so the protocols might be available early to users
of such systems. We hope there will be interest in early experimental
implementation on other computers.
In the following six months, we plan to test, evaluate, and modify the
protocols. During the latter part of this period, we plan to publish the
protocols and encourage additional groups to join the Dialnet community.
Note: This document is adapted from our NSF proposal and retains some of
that eleemosynary flavor.
For further information contact Lester Earnest or John McCarthy at Stanford
Artificial Intelligence Laboratory, Stanford University, Stanford, California
94305; ARPAnet addresses: EARNEST @ SU-AI and MCCARTHY @ SU-AI. Protocol
questions should be directed to Mark Crispin at the above address or at ARPAnet
address MRC @ SU-AI.
This document is DIALNE.MEM[DLN,MRC] @SU-AI.